I'm pretty sure I see the io impl bug that could be causing this, can you please revert any workarounds you have attempted for this bug so that I can actually track it down, don't want to just revert the commits in case they contain unrelated cleanups that you do want to keep. Also, you may have to either not use io or keep these tests disabled until it is functional.

Hmm, my idea was wrong, but for the record any stores inside a groupAsync function are intended to be visible to any loads after calling groupWait on that group, so this would have just been working around and possibly hiding some other bug.

any stores inside a groupAsync function are intended to be visible to any loads after calling groupWait on that group

Thanks for clarifying, Jacob.

Here, each thread accesses a distinct memory region and fills its own chaining value slot, and the order in which threads run or finish doesn't matter. Combined with the fact that this behavior only appears on architectures with weak memory ordering, and that even there it happens nondeterministically, is why an ordering issue is the explanation that made sense to me.

That was an opportunity to clean up the code, but if the symptoms persist, instead of disabling tests, we should probably temporarily remove anything that uses threads in std.crypto to be safe.

The mips one was in qemu on a strongly-ordered system, so no memory accesses were actually weak, and also the test itself is already non-deterministic, so that property of the failure can not be used to make other assumptions.